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1. Scope 


1.1 This specification is for the development and implemen- 
tation of secure audit data and logs for electronically stored 
health information. It specifies how to design the audit log to 
record all activities impacting a medical record, for example, 
creating a new record, entering data into a record, changing or 
deleting an existing record, and all additional user access data 
(for example, identification, location, and date and time) to 
patient-identifiable information maintained in computer sys- 
tems. Such audit logs shall track not only data entry and 
modifications, but also simple access and viewing of the 
patient record, and whether any modifications are made during 
that access. This specification also includes principles for 
developing policies, procedures, and functions of health infor- 
mation logs to document all actions regarding identifiable 
health information for use in both manually entered (paper 
record) and computer systems. 


1.2 The first purpose of this specification is to define the 
nature, purpose, and function of system access audit logs and 
their use in health information systems as a technical and 
procedural tool to help provide privacy and security oversight 
and produce a self-authenticating record that would, when 
maintained together with its audit logs, speak to and confirm its 
own integrity and accuracy of the medical and other data 
within the record. Moreover, in concert with organizational 
confidentiality and security policies and procedures, permanent 
audit logs can clearly identify all system application users who 
accessed and acted on patient identifiable information or both, 
and identify the location of the user, identify patient informa- 
tion accessed, and maintain a permanent record of actions 
taken by the user. Accomplishing the purpose of creating a 
trustworthy record thus requires the use of secure, automatic, 
computer-generated, time-stamped audit logs, which shall be 
used to independently record the identity of the user as well as 
the date, time, and location of user access, and also record all 
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entries and actions that create, change, or delete electronic 
records or other patient information. Full transparency of 
modifications or deletions or both is mandatory. For example, 
record changes shall not obscure previously recorded informa- 
tion. Such audit data and documentation shall be retained for a 
period at least as long as that required for the subject paper and 
electronic records (together, “records”), including any time 
period required by evidence preservation or litigation hold 
requirements and applicable state or applicable federal laws 
pertaining to the subject records. In no event shall the audit 
data or medical records in hard copy or electronic format be 
destroyed in advance of that date prescribed by state, federal or 
other law or regulation, when such records may be legally 
destroyed; and in any case, not before ten years or, in the case 
of a minor child, before two years after that child’s eighteenth 
birthday. If such records are for any reason maintained beyond 
this minimum requirement, then the audit logs, and the data 
contained therein, must be maintained as long as the records 
are maintained. Audit logs and healthcare information shall be 
provided when specifically requested by authorized healthcare 
providers; the patient, his personal representative, advocate, 
and/or designee; researchers; quality control personnel; and 
organizational managers or administrators or both; and other 
persons authorized to have access to patient records or patient- 
identifiable information or both in any form. 


1.3 In the absence of computerized logs, audit log principles 
can be implemented manually in the paper patient record 
environment with respect to permanently monitoring paper 
patient record access, data entry, and data modification. Where 
the paper patient record and the computer-based patient record 
coexist in parallel, security oversight and access and data 
management shall address both environments with the under- 
lying and unifying principle being transparency regarding the 
identity of the individual accessing or acting upon data in the 
record or both; the location of the individual when doing so; 
the time and date of such actions/entries; and clear visibility of 
modifications such as addenda, deletions, error corrections, and 
late entries. 


1.4 The second purpose of this specification is to identify 
principles for establishing a permanent record of disclosure of 
health information to external users and the data to be recorded 
in maintaining it. Security management of health information 
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requires a comprehensive framework that incorporates both 
mandates and criteria for disclosing patient health information 
found in federal and state laws and rules and regulations and 
ethical statements of professional conduct. Accountability for 
such a framework shall be established through a set of standard 
principles that are applicable to all healthcare settings and 
health information systems. 


1.5 The creation and preservation of logs used to audit and 
oversee health information access, actions made upon health 
information, and disclosure of health information are the 
responsibility of each healthcare provider, organization, data 
intermediary, data warehouse, clinical data repository, third- 
party payer, agency, organization, or corporation that maintains 
or provides or has access to individually identifiable data. Such 
logs are specified in and support policy on information access 
monitoring and are tied to disciplinary sanctions that satisfy 
legal, regulatory, accreditation, institutional mandates, civil 
remedies by the patient or patient’s family, and are also tied to 
authentication of medical data and a patient’s right to obtain a 
complete, accurate, and transparent set of medical data and 
metadata (for example, audit logs). 


1.6 When non-patient-specific healthcare data is sought (for 
example, analyses of aggregate patient data for internal or 
external reviews, research, or subsidies), healthcare providers 
and organizations need to also prescribe access requirements 
for such aggregate data and approve query tools that allow 
complete auditing capability or design data repositories that, in 
an active query, can limit inclusion of data in end-product 
aggregate form that reveals potential keys to identifiable data. 
In other words, endproduct aggregate-patient data shall not 
contain patient-identifying data or elements that, through 
analysis, can be used to identify individuals through inferences. 
For example, fields such as birth date, sex, race, or relevant 
demographics, and medical records numbers, or combinations 
thereof, are analyzed together for research purposes, using 
software that matches data elements across databases, thereby 
allowing identification of specific patients through inferencing, 
while preserving patient privacy. Audit data and logs can be 
designed to work with such applications, if the query functions 
are part of a defined retrieval application, but the end-product 
data is safeguarded to protect patient identity from release. This 
specification applies to the disclosure or transfer of health 
information (records) whether as individual files or in batches. 


1.7 This international standard was developed in accor- 
dance with internationally recognized principles on standard- 
ization established in the Decision on Principles for the 
Development of International Standards, Guides and Recom- 
mendations issued by the World Trade Organization Technical 
Barriers to Trade (TBT) Committee. 


2. Referenced Documents 
2.1 ASTM Standards:* 


2 For referenced ASTM standards, visit the ASTM website, www.astm.org, or 
contact ASTM Customer Service at service@astm.org. For Annual Book of ASTM 
Standards volume information, refer to the standard’s Document Summary page on 
the ASTM website. 


E1869 Guide for Confidentiality, Privacy, Access, and Data 
Security Principles for Health Information Including Elec- 
tronic Health Records (Withdrawn 2017)° 

E1986 Guide for Information Access Privileges to Health 
Information (Withdrawn 2017)° 


2.2 Federal Standards: 

21 CFR 11 Subpart B(e) Electronic Records 

42 CFR, Part 2 Confidentiality of Alcohol and Drug Abuse 
Patient Records 


3. Terminology 


3.1 Definitions: 

3.1.1 access, n—the provision of an opportunity to 
approach, inspect, review, retrieve, store, communicate with, or 
make use of health information resources (for example, 
hardware, software, systems or structure) or patient identifiable 
data and information, or both. 


3.1.2 access report—record that is a subset of the clinical 
audit report” documenting the following information about 
each access of patient medical information: user identification 
(the person accessing the record); the date and time of the 
access (documenting both start and exit times spent on each 
record accessed); total duration of access; specific terminal, 
hardware, or location from which the access occurred; type of 
action (for example, copy, print, addition, modification, and 
deletion to the record, and when any access has been made, 
even when the user makes no entry or change); specific patient 
data accessed. 


3.1.2.1 Discussion—The above access information is an 
indispensable part of the medical record because it is clinically 
relevant and does not appear in certain iterations of the record. 
All accesses shall be recorded, and the entire access record 
shall be provided when an access record is requested. 

3.1.3 audit data, n—complete historical record of entries 
regarding patient care information automatically collected and 
stored by electronic health records (EHR) software or, in the 
case of paper records, collected and stored as a matter of 
industry standard and related policy and procedure. 


3.1.3.1 Discussion—This data collection includes informa- 
tion entered or altered (changed or deleted) by users or 
processes and information concerning all users who accessed 
or who made, changed, or caused entries to be made into the 
EHR or paper medical record. In the case of EHR, this 
collection includes, but is not limited to, information regarding 
demographic data about the user and facts about access and 
actions taken by the user, such as date, time, location, and area 
of record accessed/actions taken, and the actions taken by the 
user or process in the record, such as creation, queries, views, 
additions, modifications, deletions, and so forth. 

3.1.4 authentication, n—confirmation that a record is what it 
purports to be, an accurate depiction of a patient’s medical care 
and data; the act of establishing a record, or other document, as 


3The last approved version of this historical standard is referenced on 
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genuine, trustworthy and official; the provision of such assur- 
ance of the record’s authenticity is possible only because of the 
audit log and data associated therewith. 


3.1.4.1 Discussion—Authentication of the record is possible 
only when the associated audit data relating to the record is 
made an indispensable part of the medical record. (1), 
3.1.5 authorization, n—the mechanism for obtaining con- 

sent for the use and disclosure of health information. 
((1), AHIMA) 


3.1.6 authorize, v—the granting to a user the right of access 
to specified data and information, a program, a terminal or a 
process. 


3.1.7 certificate, n—certificate authority (CA) states a given 
correlation or given properties of persons or information 
technology (IT) systems are true. 


3.1.7.1 Discussion—If the certificate is used to confirm that 
a key belongs to its owner, it is called a key certificate. If the 
certificate is used to confirm roles (qualifications), it is called 
an authentication certificate. 

3.1.8 change, v—to alter or edit information previously 
recorded in health information technology, for example, by 
addition or deletion. 


3.1.8.1 Discussion—Information previously recorded shall 
not be changed without the retention of prior value(s). Change 
shall be retained as an audited event and in a viewable format 
that identifies the previous (and now changed) information in a 
patient’s record (similar to how one might see changes repre- 
sented by redlining in a word-processing application). How 
such changes are displayed or produced or both in exported 
electronic or printed form is a design decision left to EHR 
technology developers." 

3.1.9 clinical audit report, n—report created using audit 
data collected and stored within the EHR. 


3.1.9.1 Discussion—Audit data can be aggregated into re- 
ports used to respond to a particular query or user’s activity in 
the EHR. Audit data can also be aggregated into reports, 
commonly called “audit logs” or “audit trails’ drawn from 
entire collections of data that have been automatically collected 
in the course of patient healthcare. An “access report” is one 
example of a report that can be generated to respond to the 
questions of which users have gained access to an individual’s 
health information and what such users did during such access. 

3.1.10 confidential, adj—status accorded to data or informa- 
tion indicating that it is sensitive for some reason, and 
therefore, it needs to be protected against theft, disclosure, or 
improper use, and must be disseminated only to patient— 
designated individuals or organizations with an approved need 
to know (1). 


3.1.11 data dictionary, n—description in ordinary language 
of every table, data object, classification, or category of data, or 
combinations thereof, contained in the database, including the 
properties of each table, data object, and data classification, as 


4 American Health Information Management Association. 
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well as an ordinary language description of any abbreviations 
or coded information recorded in the database. 


3.1.11.1 Discussion—The data dictionary serves as a legend 
by which the information in the database can be queried and 
through which reports can be decoded. The data dictionary also 
explains the connections and dependencies of the tables within 
the database. 

3.1.12 database, n—collection of data organized for rapid 
search and retrieval (2). 


3.1.13 database security, n—refers to the ability of the 
system to enforce security policy governing access, creation, 
modification, or destruction of information. 


3.1.13.1 Discussion—Unauthorized creation or destruction 
of information is an important and substantial threat that shall 
be addressed via proactive database security measures. 

3.1.14 disclosure, n—to access, release, transfer, or other- 
wise divulge health information to any internal or external user 
or entity other than the individual who is the subject of such 
information. 


3.1.15 health information, n—any information relating to 
the past, present, or future physical or mental health or 
condition of an individual, the provision of healthcare to an 
individual, or the past, present, or future payments (for 
example, coding and billing) for the provision of healthcare to 
a protected individual; and that identifies the individual with 
respect to which there is a reasonable basis to believe that the 
information can be used to identify the individual. This 
information may exist in any form or medium, which is created 
or received by a healthcare provider, a health plan, health 
researcher, public health authority, instructor, employer, school 
or university, health information service, or other entity that 
creates, receives, obtains, maintains, uses, or transmits health 
information, such as a health oversight agency, a health 
information service organization or other (2). 


3.1.16 information, n—data to which meaning is assigned, 
according to context and assumed conventions. 


3.1.17 integrity, n—as it relates to health information, it 
means that the information/record is accurate, complete, and 
immutable in that all actions taken with respect to the record 
are transparent. 


3.1.17.1 Discussion—The integrity of a record containing 
health information is verified as trustworthy and authentic by 
maintaining all audit data, which shall be enabled by default 
(that is, turned on), immutable (that is, unable to be changed, 
overwritten, or deleted), and able to record not only which 
action(s) occurred, but more specifically the electronic and 
other health information to which the action applies. 

3.1.18 privacy and security audit report—intended to cap- 
ture a forensic reconstruction of events that occurred on a 
patient record. 


3.1.18.1 Discussion—One important audience of the pri- 
vacy and security audit report is security officers and privacy 
officers who are relying on the privacy and security audit report 
to determine if inappropriate use or disclosure of patient data 
occurred. When a user performs a create, access, update, 
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change, delete, copy, print, query (search), or user permission 
change that affects a patient record, the system shall audit the 
following information: user identification, patient 
identification, the date and time, location from which the event 
occurred, type of action, and summary of patient data accessed. 
For query (search) events, a summary of the search criteria that 
was used may be audited instead of the list of patient records 
returned by the search. If the access is an emergency access 
(for example, “break glass”), the user or accessor shall docu- 
ment his or her reason for access. 

3.1.19 self-authenticating, adv—having the capacity to 
maintain and demonstrate the integrity and accuracy of all 
actions and data within the electronic medical record so that the 
record is trustworthy. 


3.1.19.1 Discussion—Audit data is integral to self- 
authentication and trustworthiness of patient information in- 
cluding the medical record and billing record. 

3.1.20 transaction log, n—specific type of report showing 
all of the content changes in a record that can be generated 
from audit data for the purpose of reconstructing the substan- 
tive record if the record is lost or destroyed. 


3.1.21 user, n—person authorized to view or use, or both, 
the information contained in an information system as specified 
by their job function. 


3.1.21.1 Discussion—The patient shall be designated an 
authorized user since the underlying patient information per- 
tains to that patient. Health care providers and support/ 
administrative personnel may be designated as authorized users 
by statute or institutional policy. A user also may refer to 
automated processes that touch the record, such as internal and 
external systems that push data into or draw data from a record, 
for example, laboratory results. (There shall be no access given 
to data that provide individually identifiable healthcare infor- 
mation to any automated process.) 

3.1.22 user identification, user ID, n—combination name/ 
number biometric assigned and maintained in security proce- 
dures for identifying and tracking individual user activity. 


3.1.23 view—designated configuration for data/information 
extracted from information system(s) and presented through a 
workstation. 


4. Significance and Use 


4.1 Data that document health services in health care 
organizations are business records and shall be archived to a 
secondary but retrievable medium, and readily accessible, such 
as data that would be archived in a server or cloud storage. 
Audit data shall be retained for as long as the medical record 
is maintained, and may not be destroyed before the medical 
record may legally be destroyed, and in any event, for at least 
10 years or for two years after the legal age of majority, unless 
a longer period of record retention is prescribed by state, 
federal or other law or regulation. 


4.2 The purpose of audit data and disclosure logs is to 
document and maintain a permanent, trustworthy, and immu- 
table record of all authorized and unauthorized activities of any 
nature whatsoever and disclosure of confidential health infor- 
mation {except exclusions per federal and state law [21 CFR 


11 Subpart B(e)]}. This further facilitates the purpose that 
patients, healthcare providers, organizations, and others can 
obtain a verifiable, self-authenticating record documenting all 
activities with respect to that record. The process of informa- 
tion disclosure and auditing shall also conform, where relevant, 
with the Privacy Act of 1974 (3). 


4.3 Audit reports designed for system access provide a 
precise capability for healthcare providers, organizations, 
patients, patient representatives, and advocates to see who has 
accessed and/or manipulated patient information. Because of 
the significant risk of medical information manipulation in 
computing environments by authorized and unauthorized 
users, the audit report is an important management tool to 
monitor access and any such manipulation retrospectively. In 
addition, the access and disclosure logs become powerful 
support documents for disciplinary and legal actions. 
Moreover, audit reports are essential components to compre- 
hensive security programs in healthcare and vital for the 
privacy rights of the individual. A patient has a right to know 
who has accessed their patient information and what occurred 
during such access. Access by any means (viewing or any other 
action) regarding the patient record and/or audit log or the data 
contained therein by attorneys, risk management, or similar 
individuals or entities are not privileged actions and must also 
be fully transparent and disclosed. 


4.4 Healthcare providers and organizations are accountable 
for managing the disclosure of health information in a way that 
meets legal, regulatory, accreditation, and licensing require- 
ments and growing patient expectations for accountable pri- 
vacy practices. Basic audit data procedures shall be applied, 
manually if necessary, to paper patient record systems to the 
extent necessary to protect patient privacy and to allow 
authentication of the paper record. 


4.5 Medical records with integrity and trustworthiness are 
essential to promote safe and appropriate healthcare, billing, 
research, and quality control initiatives and are protective of all 
individuals involved in healthcare delivery and receipt. Con- 
sumer fears about confidentiality of health information and 
legal initiatives underscore disclosure practices. Technology 
exists to incorporate audit functions in health information 
systems. Institutions are accountable for implementing com- 
prehensive confidentiality, security, and patient information 
audit programs that combine social elements, management, and 
technology. 


4.6 This specification also responds to the need for a 
standard addressing privacy and confidentiality as noted in 
Public Law 104-191 (2), or the Health Insurance Portability 
and Accountability Act of 1996, and the need for a self- 
authenticating record that will verify accuracy and integrity. 


5. Additional Audit Confidentiality and Security 
Functions in Health Information Systems 


5.1 Audit data memorializes actions (for example, queries, 
views, additions, deletions, changes, copy, print, and copy and 
paste) performed on patient medical information by users. 
Actions are recorded at the time they occur. All actions shall 
include user authentication, user- or system-directed signoff, 
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and the specific name of the medical section record tab (name 
of section per software naming convention) to which the action 
pertains. Time stamps, including date and time, shall be 
automatically generated and recorded by the system at the time 
the entries for the actions were made. The timing of the 
medical event to which the record entry refers is also recorded 
as a separate data point, which is available as a filter in an audit 
logs. If a user makes a late entry (“late” per the prevailing 
industry standard definition), an explanation for every late 
entry shall be documented. Audit data also contain the location 
of access to the patient’s records (electronic or otherwise), for 
example, the specific computer terminal used. 

5.1.1 Health record content (transformation/translation via 
interfaces, interface engines, and gateways between heteroge- 
neous applications) shall be maintained in the different formats 
and appearances of the reports generated through interfaces. 


5.2 Other database tables are needed to link the items in 5.1 
and 5.1.1 to satisfy inquiries and to produce useful reports. 
Including unique user identification, for example, number, user 
name, work location, and employee status (permanent, 
contract, temporary) provides essential user information. Audit 
data shall be captured for all software systems that are used to 
access or manipulate patient information. Multiple reports may 
be required to provide a complete audit log for a patient’s 
record when multiple software systems are in use. 


5.3 While audit data shall always include the identity of the 
user, the location of access, identification of the specific 
record(s) accessed, the type of specific actions taken, and date 
of such actions, the following functions shall also be performed 
when auditing solely for patient confidentiality and security 
reasons: 


5.3.1 Such patient confidentiality and security audits shall 
identify and track an individual user’s access, including au- 
thentication and signoff, to a specific patient’s or provider’s 
data. This function shall occur in real time and be captured in 
audit data. In the paper patient record, at a minimum, a 
permanent charge copy of all external releases shall be kept. An 
audit log review can be authorized by the patient, guardian, 
designated patient representative, or advocate, provided by 
law, or granted in an emergency. This may be a computer file. 

5.3.2 During such audits, unauthorized changes, additions, 
and deletions to a patient’s health information shall be reported 
to and investigated by the guardian/custodian/steward of 
patient/health information/medical records. 

5.3.3 Such audit systems shall record and maintain breach 
access flags. Flags shall notify a security administrator and the 
guardian/custodian/steward of patient/health information/ 
medical records that potential breaches may be occurring or 
have occurred. Organizations shall be able to tailor flags to 
meet their requirements. For example, restricted health data 
may be flagged in one organization, high profile individuals’ 
[that is, celebrity, employees, very important persons (VIPs), 
and providers] data may be flagged in another. 

5.3.4 Maintain user identification data. Doing so shall in- 
clude a user identification code, full name, employment status, 
location of workstation, laptop, and so forth, from which he or 
she has been authorized to access the patient health record and 


the access authorization based on role and job function that is 
assigned by the organization. 

5.3.5 Allow cross reference to user employment, work 
location, or contract status with an authorized access code. 

5.3.6 Allow easy retrieval. Audit log queries must be 
efficient to operate and provide easy, on demand reporting 
within a reasonable time frame. 

5.3.7 Provide search capability to authorized users and the 
patient, his or her advocate, designee, or representative of any 
or all data objects. Doing so allows the capability to query 
access patterns to identify exceptions and allows programs to 
be written to generate exception reports related to known 
access patterns. 

5.3.8 Provide the capability for predetermined flags to 
generate audit summary reports by designated schedule and 
ad-hoc reports within a reasonable timeframe. 

5.3.9 Organizational measures and a specific security envi- 
ronment for the audit log device shall support the required 
security level to prevent access by unauthorized users. 

5.3.10 In addition to maintaining the integrity of the record, 
audit logs are mandatory for detecting and enforcing breaches 
in health information systems. 

5.3.11 Support real-time search and retrieval capabilities. 

5.3.12 Reconstruct data resulting from access to the health 
record content for any given historical date/time or range 
thereof, including to the present. Document the chronology, 
continuity, and completeness of the health record event by 
event for patient or provider. 


6. Principles for Health Information Disclosure 
Oversight in Paper and Computer-based Health 
Information Systems 


6.1 Disclosure of health information shall be made only by 
those appropriately trained and qualified to do so. Disclosures 
shall be consistent with industry standards, the organization’s 
policies and procedures, and federal and state statutes and 
regulations. 


6.2 Disclosures of health information pursuant to patient 
authorization should be documented. 


6.3 Disclosure of health information pursuant to subpoena 
or court order should be documented in the health record. 


6.4 Disclosure of information relating to alcohol and drug 
abuse treatment should be made pursuant to the federal 
regulations (42 CFR, Part 2) (4). The regulations require that 
each disclosure must be accompanied by a notice prohibiting 
redisclosure. The notice states the following: 

“This information has been disclosed to you from records whose 

confidentiality is protected by Federal law. Federal regulations (42 

CFR, Part 2) prohibit you from making any further disclosure of it 

without the specific written consent of the person to whom it pertains, 

or as otherwise permitted by such regulations. A general authorization 

for the release of medical or other information is not sufficient for this 

purpose.” 

6.5 In a medical emergency, the 42 CFR, Part 2 federal 
regulations do permit disclosure to medical personnel to treat a 
condition that “poses an immediate threat to the health of the 
patient.” Such disclosure should be documented. 


6.6 A verbal disclosure under 42 CFR, Part 2 should be 
documented and must be accompanied or followed by the 
required notice prohibiting redisclosure. 


7. Audit Data and Audit Report Content 


7.1 Audit log content is determined by regulatory 
initiatives, accreditation standards, and principles and organi- 
zational needs. Information is needed to adequately understand 
and oversee access to patient identifiable data in health 
information systems in order to perform security oversight 
tasks responsibly. Logs must contain the following minimum 
data elements: 

7.1.1 Date and Time of Access Event—The exact date and 
time of the access event and the exit event. 

7.1.2 Date and Time of Activity—The time to which the data 
entered refers, if not contemporaneous with user’s data entry 

7.1.3 Duration of Access—The start and stop times in which 
each specific data point was accessed. 

7.1.4 Access Device—Terminal or work station or device 
from which the user obtained access. 

7.1.5 Location of Access or Activity or Both—For a fixed 
non-mobile access device, the specific computer terminal, 
hardware, or location wherein the patient record is accessed, or 
actions are performed on the patient’s record or both. 

7.1.6 Patient Identification—Unique identification of the 
patient to distinguish the patient and his/her health information 
from all others. 

7.1.7 User Identification—Unique identification of the user 
of the health information system. 

7.1.8 Type of Action (for example: creations, additions, 
deletions, changes, queries, accesses, copy, print, and copy and 
paste)—Specifies inquiry, any changes made (with pointer to 
original data state), and a delete specification (with a pointer to 
deleted information). 

7.1.9 Identification of the Patient Data that is Accessed— 
Granularity should be specific enough to clearly determine if 
data designated by federal or state law as requiring special 
confidentiality protection has been accessed. Specific category 
of data content, such as demographics, pharmacy data, test 
results, and transcribed notes type, should be identified. 

7.1.10 Source of Access—The identification of the applica- 
tion through which the access occurred. 


8. Mandatory Disclosure Log Content 


8.1 The disclosure log content shall include: the date, name, 
and address of the individual or entity to which the information 
is sent; description of information sent, including patient 
identity; reason for disclosure; and the identity of the indi- 
vidual handling the disclosure. For routine or basic disclosure, 
the following are required: 

8.1.1 Date and time of disclosure, 

8.1.2 Reason for disclosure, 

8.1.3 Description of information disclosed, 

8.1.4 Identity of person requesting access, 

8.1.5 Identity and verification of the party receiving the 
information, 

8.1.6 Identity of the party disclosing the information, and 

8.1.7 Verification method of requesting the party’s identity. 
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8.2 Legal Disclosure—The court docket number, names of 
the parties, the name and location of the court where the 
proceeding is held, and a description of the documents pro- 
vided should be provided. Details are as follows: 

8.2.1 Date and time of disclosure, 

8.2.2 Reason for disclosure, 

8.2.3 Description of information disclosed, 

8.2.4 Identity and verification of the party receiving the 
information, 

8.2.5 Identity of the party disclosing the information, 

8.2.6 Verification method of requesting the party’s identity, 

8.2.7 Court docket number, 

8.2.8 Names of the parties, and 

8.2.9 Name and location of the court. 


8.3 Records of disclosures for emergency purposes must be 
maintained according to Guide E1986. All emergency accesses 
should follow standard auditing procedures. Patient’s name 
and case number include the following information: 

8.3.1 Date and time of disclosure, 

8.3.2 Description of circumstances that required emergency 
disclosure, 

8.3.3 Description of information disclosed, 

8.3.4 Identity of person requesting access, 

8.3.5 Identity and verification of the party receiving the 
information, 

8.3.6 Identity of the party disclosing the information, and 

8.3.7 Verification method of requesting party’s identity. 


9. Audit Data Reports 


9.1 Standard access and disclosure reports as well as the 
audit logs, and the data contained therein, shall be provided to 
security officers or privacy officers and designated individuals, 
such as data custodians, data stewards, and work area manag- 
ers. Without exception, patients or personal representatives or 
both, advocates, or their designees shall have access upon 
request to disclosure reports, as well as audit logs, and the data 
contained therein. Standard access and disclosure reports 
provided to security officers or privacy officers and designated 
individuals such as data custodians, data stewards, and work 
area managers shall also include, but not be limited to, periodic 
random samples of all who seek information to identify 
individuals who have accessed patient identifiable data. 


9.2 Ad hoc reports should be available for authorized 
parties, such as privacy or security officers or managers. 


9.3 Variation—Reports should be available to report access 
variations for individuals and for departments. This should 
include the capability of an authorized requester to query the 
application to generate a report on a unscheduled basis. This 
feature is called for so that prompt response can be provided 
for incidents that are identified as a potential security breach. 
Managers should be able to specify queries that arise from 
patient, provider, or employee complaints, or a combination 
thereof. 


9.4 On-demand reports (requests that are made with a 
reasonable time frame) to providers and patients should be 
available to provide the record of access to confidential health 
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information. Reports should include identification of the indi- 
vidual who accessed the information, date of access, and the 
reason for access if the reason for access is maintained. 


9.5 An audit log should be able to be used to determine the 
following: 

9.5.1 When specifically requested by a patient (via provi- 
sion to and analysis by the patient individually or via provision 
to and analysis by the patient’s personal representative, their 
designee, or their advocate), determine the users who viewed 
data on this person, including their identity and determine the 
date/time of access, activity, specific action taken (creation, 
views, additions, deletions, queries, accesses, copy, print, copy 
and paste, and other changes performed on data), determine the 
specific section of the record on which the action occurred, and 
determine the terminal or workstation or device location from 
which the user obtained access; 

9.5.2 For a given user, determine which data content cat- 
egories were viewed or otherwise acted upon, or both; 

9.5.3 Determine the changes that are made to this patient 
record (over a given time frame); and 

9.5.4 Determine how many copies of a specific set of data 
have been made and the circumstances of each copy, including 
the form of the copy (electronic or paper) and where and to 
whom the copy was directed. 


9.6 Patients and providers should have access to the perma- 
nent record of disclosures of health information to external 
users. 


10. Sanctions 


10.1 Enterprise sanctions should be invoked when audit log 
inquiry reveals that confidentiality has been breached. Organi- 
zations must have policies and procedures regarding disciplin- 
ary actions and sanctions, which are communicated to all 
employees, agents, and contractors. Examples of sanctions 
include verbal warning, notice of disciplinary action placed in 
personnel files, removal of system privileges, termination of 
employment and contract penalties (Guide E1869). 


10.2 In addition to enterprise sanctions, employees, agents, 
and contractors must be advised of civil or criminal penalties 
for misuse or misappropriation of health information. 


10.3 Employees, agents, and contractors must be made 
aware that violations may result in notification to law enforce- 
ment officials and regulatory, accreditation and licenser orga- 
nizations. 


11. Keywords 


11.1 audit log; disclosure; electronic health record; health 
information systems 
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